US
CA
AU
NZ
From October, NHS hospitals are expected to use new Transfer of Care standards to compile discharge summaries and clinic letters for GPs. NHS Digital has said these will be sent using FHIR messages directly into GP systems. Orion Health experts Dr David Hay and Anne O’Hanlon explain.
Fast Healthcare Interoperability Resources (FHIR) is the latest generation standards framework from HL7 International. The inspiration for FHIR came from an HL7 meeting, at which people said: ‘HL7 v3 is just too hard. We should be doing what the web companies are doing, and thinking about the people who want to use these services. We should be designing standards with the implementers in mind.’
What is different about FHIR is that it supports many paradigms of interoperability: messages, queries, operations and documents. You can use the same jigsaw pieces, known as resources, over and over again to solve different problems. FHIR also uses web standards and interface patterns that emerged in other industries during the Web 2.0 era, such as RESTful APIs.
Because developers are already familiar with them, they can focus on collecting data and using it in creative ways, rather than getting bogged down learning the lingo of healthcare exchange formats – PID segments, EDIFACT and Kettering XML to name but a few!
That means that although FHIR started out as being about solving interoperability challenges, we are seeing it used for many other things, such as a data model for persisting data or representing clinical knowledge. It is seen as a pre-requisite for unlocking data for population health and genomics.
People have wanted to do these things for a long time and suddenly something has come along that lets them. That’s FHIR, and the global FHIR community. Indeed, the community is one of the major assets of FHIR.
FHIR is a tool, not “the solution”
The risk we are now facing, and that we have to manage, is that people are starting to see FHIR as “the solution”; and it is not. There are plenty of other challenges. For example, we have been finding that a lot of healthcare data is “crappy”. That’s not intended to be a derogatory term, but there is a common misconception that data captured in one clinical encounter will be fit for use for another clinical encounter – and that is not always the case.
Poor quality data often doesn’t come to light until it is being shared and scrutinised by other clinicians caring for the same individual, or when it is used for a secondary purpose such as analytics. Often, it is nobody’s fault that the data is dirty but simply a reflection of it being out of date, not specific enough, or captured in an entirely different context, such as statutory reporting.
Then there is the challenge of clinical practice: data considered ‘good enough’ within one specialty may be of little or no use to a clinician working in a different specialty. It may be sufficient for a pharmacist to know that someone has a cancer diagnosis; but an oncologist will want to know the exact tumour site(s), grade, malignancy, and so on.
This kind of challenge is something that we need to keep in mind over the next few months, as hospitals and vendors get ready to implement the new Transfer of Care standard. English hospitals must use this standard to send structured, coded discharge summaries, emergency care discharge summaries, and outpatient clinic letters to GPs from October.
In July 2017, NHS Digital announced that these documents would be sent using FHIR. It specifically said that it did not want to use HL7 v3 CDA anymore, because FHIR had become the “international industry standard” and the NHS would face “greater clinical risk and higher costs” if continued with HL7 v3 CDA and then undertook a complex migration to FHIR later.
We think this was the right thing to do, and we have been delighted by how people have engaged with the decision. However, it is not going to solve all the problems. Sending a discharge document in FHIR is great, but producing that document will not be easy. At the moment, you have people putting together PDF documents and sending them over to GP practices. Now, they are going to have to create fully structured documents, using the headings developed by the Professional Record Standards Body and the Academy of Royal Medical Colleges. That is going to be a big change; particularly for outpatient departments, where letters are usually dictated.
We need an incremental approach
Hospitals do seem to be engaging on the headings; but they have not moved as much on coding data. NHS Digital has mandated SNOMED CT as a structured clinical vocabulary for use in electronic health records; but it won’t become an NHS standard until 2020. Likewise, medication data must become dm+d coded, which is a massive challenge given the current backdrop of paper-based prescribing and proprietary pharmacy formularies in many NHS hospitals.
So, we think the October 2018 deadline looks optimistic, and there may need to be an incremental approach. For example, we could define a minimally viable solution, such as FHIR-ising a PDF document (carrying a PDF inside a FHIR message).
There isn’t much direct benefit to doing that, but it would make the first milestone much simpler, so that everyone can jump on-board with FHIR. Also, once we started, we could make sure that all the metadata was in the right place, and the content sitting under the right headings. Then, we could gradually work on replacing the content with structured and coded data, which would enable a fully semantically interoperable FHIR document to be generated.
Safety is paramount; and change can’t be rushed
Another reason for taking this step-by-step approach is that patient safety is paramount. In New Zealand, we were involved in an e-discharge project some years ago, using HL7 v2, and it was fraught. We had to prove to clinicians in hospital that GPs were seeing the same information as they had entered, and that the whole process (end-to-end) was clinically safe. One supplier had missed a field that could have been critical. Fortunately, the problem was picked up early; but if it hadn’t been, it could have undermined confidence in the whole project.
Recognising that e-discharge is a complex business process, we should also look to learn from other complex, enterprise-wide system roll-outs. For example, we know from experience that when hospitals do medicines management projects they deliberately roll-out at a pace of one or two wards a fortnight, so that they can train as many staff as possible, allowing for shift workers, illness and holidays.
Then, there are the soft, human factors. Convincing an over-stretched junior doctor or clinical nurse specialist to invest more time writing a discharge letter is a tough sell when, on the face of it, the recipient benefits more than the sender.
Creating Transfer of Care documents in FHIR will make it easier for diagnosis, allergy and medication data to be consumed, shredded and imported directly into the GP’s record (in addition to existing as a read-only document attached to the record). This should reduce transcription errors and the time staff spend filing and re-keying information.
Helping hospital staff to grasp this bigger picture, and to understand how it will eventually reap benefits for them and their patients is vital, if they are to change the way they work. The IT system itself must also be simple enough to use so that the focus of the training and the change management conversation is more about ‘why?’ and ‘what’s in it for me?’ than ‘click here and type this.’
Coding clinical data is complex, and it will take time for people to adjust – even with a decent user interface. Physically getting around every ward of a major acute trust can present a challenge, but when it comes to winning hearts and minds nothing beats a face-to-face conversation.
People need to understand why what is being done is being done, why it matters, what’s in it for them and what they will need to do differently. Continuing to be on hand, so staff can ask questions and provide direct feedback on what is working or not working, is also important to drive uptake. Standards don’t implement themselves.
Moving carefully in the right direction
When it comes to sharing information, we are much further forward than we were five years ago. Back then, there were still arguments about who owned data, and what could be shared, and what standards should be used for any sharing that took place.
Since then, the introduction of the EU General Data Protection Regulation (GDPR) has focused people’s attention on data security and raised the profile of data portability. Use of FHIR has grown significantly. This is reflected in the revised Transfer of Care initiative and the introduction of CareConnect APIs, which NHS England expects all clinical system suppliers outside of primary care to support from December 2018.
NHS Digital has set a vision for a new gold standard, and that is what everybody is working towards. What’s different between this and previous standards adoption drives is that, for the first time in England, vendors, IT staff, clinicians, informaticians and industry experts have collaborated on a weekly basis to curate and design the information models, providing feedback on the practicality and potential problems of the standards before they are ratified.
INTEROPen has facilitated this engagement, encouraging all types of vendors and clinicians to be involved. This means that, again for the first time, the resources will be generic and reusable across many different clinical scenarios, rather than being designed for and piloted in one care setting (such as GP Out of Hours services) and then re-worked for other settings.
However, with just three months to go, we are not sure just how ready hospitals and vendors are (and, of course, new issues will arise as actual implementations occur). NHS England issued a survey to hospital trusts recently, asking them to assess their level of readiness for the upcoming Standard Contract changes. Similarly, vendors were surveyed by INTEROPen in July 2018 to understand their product development roadmaps and any challenges they were facing that might delay implementation.
All this is very, very positive. So, we absolutely do not want to take our foot off the accelerator, but we do need to understand that this is a journey. We have a clear direction of travel. Everybody is on board. But we need to understand that there will be bumps in the road, and that we will need to move forward incrementally.
About Dr David Hay: Dr David Hay graduated from medical school in 1981, but quickly moved into health IT, and is now a product strategist for Orion Health. He describes himself as “a FHIR evangelist” and is chair emeritus of HL7 New Zealand and co-chair of the FHIR Management Group.
About Anne O’Hanlon: Anne O’Hanlon trained first as a musician and then as a computer scientist, specialising at post-grad level in artificial intelligence. She is now solution consulting director at Orion Health and represents IT vendors on the INTEROPen Board. She describes herself as “passionate about health informatics and the role IT can play in bringing about a revolution in how care is delivered.”
Useful links:
Introduction to FHIR; video by David Hay
